The Internet Group Management Protocol (IGMP) is described in Request For Comments document No. 1112 (hereinafter referred to as RFC-1112 and as IGMP version 1) and in Request For Comments document No. 2236 (hereinafter referred to as RFC-2236 and as IGMP version 2). Through the use of various IGMP messages, a requesting system (i.e. an end user download device) is able to facilitate joining and leaving one or more multicast groups. Thus, the requesting system device may selectively receive one or more streams of multicast information.
Conventional operation of the IGMP RFC-2236 (IGMP Version 2) makes provisions for a multicast routing device to automatically determine when multicast streams are no longer required. Specifically, IGMP Version 2 allows multicast routers to determine when no hosts on a particular interface need to receive one or more multicast streams any more. When a multicast router has reached such a determination, the multicast router may take steps to turn the multicast stream off.
To this end, multicast routers query each of their attached networks periodically to determine which multicast streams are still required by one or more hosts on that network. If the multicast router does not receive a response for a particular multicast stream, it retransmits the query one or more times before assuming that no hosts require that particular multicast stream any more. These retransmissions are to account for loss or error in one of the query messages or its responses. The multicast router will only turn off a multicast stream on a particular network when it is sure that there are no longer any hosts on that network wanting to continue receiving it. The interval between the last host no longer requiring a stream and the time at which the multicast router recognizes this is called “the leave latency”.
As a partial improvement to the leave latency, hosts may issue a special “IGMP Leave” message. The IGMP Leave message is intended to cue the multicast router into commencing the check for remaining hosts. The IGMP Leave message reduces the average leave latency for a particular multicast stream somewhat (by prompting the router to immediately commence the query cycle for that group). However, the IGMP Leave message does not substantially reduce the leave latency.
This conventional IGMP Version 2 Leave message mechanism is relatively slow compared with the speed that a subscriber (e.g. a video service subscriber) would “zap” from channel to channel (i.e. change channels). This conventional IGMP Version 2 Leave message mechanism typically takes as much as tens of seconds to confirm that a stream is no longer required. A channel zap should be as fast as practical and certainly is no longer than about one second.
A limitation of IGMP Version 2 is that when any terminal issues an IGMP Leave message, the multicast router is typically not sure whether there are any other subscribers receiving the same multicast stream. Accordingly, the multicast router cannot immediately stop transmitting the multicast stream. Instead, IGMP Version 2 facilitates broadcast of a group specific membership query and then waits to see if any other hosts respond. If no other terminals respond within a prescribed timeout and retransmit period, the multicast router may then stop transmission of the multicast stream.
For some Digital Subscriber Line (DSL) applications, this conventional IGMP Version 2 behaviour is not completely acceptable due to the capacity of a DSL line (or a subtending DSLAM link) being finite. There are several problems caused by such finite capacity. For example, when a subscriber download device starts quickly zapping through channels, several zaps could be received at an IP Gateway in the time it takes for a conventional IGMP version 2 implementation to query a particular multicast router for other group members and then remove the unnecessary groups. If the IP Gateway cannot facilitate deletion of a group that is no longer required quickly enough, the capacity of the DSL line will quickly be exhausted with the channels that the subscriber has zapped past, but that are still active. A point will be reached where the subscriber cannot zap to another channel because their DSL line is completely full of traffic from the channels that the subscriber has already zapped past.
Another limitation of IGMP Version 2 is that IGMP Version 2 requires that all hosts and routers revert to IGMP Version 1 mode whenever an IGMP Version 1 format message is seen on the network interface. IGMP Version 1 does not include the Leave message. Accordingly, leave latencies are therefore longer (on average) than for IGMP Version 2.
Therefore, facilitating processing of IGMP messages in a manner that overcomes time and resource limitations associated with conventional implementations of IGMP is useful.